home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part1 / 5002 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.4 KB
  1. Path: mail2news.demon.co.uk!ues5.cern.ch
  2. From: Dan Pop <Dan.Pop@cern.ch>
  3. Newsgroups: comp.lang.c
  4. Subject: Re: What does the -O option do???!!!
  5. Date: Mon, 12 Feb 1996 01:13:35 +0100
  6. Organization: CERN European Lab for Particle Physics
  7. Message-ID: <9602120013.AA06318@ues5.cern.ch>
  8. References: <4ehger$cj9@mark.ucdavis.edu> <823827008snz@genesis.demon.co.uk> <4fiphrINNrvr@keats.ugrad.cs.ubc.ca> <9602102332.AA09466@dxmint.cern.ch> <4flhrhINNtj@keats.ugrad.cs.ubc.ca>
  9. X-NNTP-Posting-Host: ues5.cern.ch
  10. X-Newsreader: NN version 6.5.0 #7 (NOV)
  11. X-Mail2News-Path: mail1.cern.ch!ues5.cern.ch
  12.  
  13. c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku) writes:
  14.  
  15. >In article <9602102332.AA09466@dxmint.cern.ch>,
  16. >Dan Pop  <danpop@mail.cern.ch> wrote:
  17. >>c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku) writes:
  18. >>
  19. >>>... as long as it is not hard-coded to treat identifiers like "free" specially. 
  20. >>
  21. >>A compiler is free to treat identifiers like "free" specially after the
  22. >>relevant header has been included.
  23. >>
  24. >>>If you write your own free() with different semantics, you would not want the
  25. >>>compiler messing with that. 
  26. >>
  27. >>If you write your own free() you invoke undefined behaviour and you can't
  28. >>expect the compiler to behave in a sensible way.  The implementation 
  29. >>namespace is a big taboo in C.
  30. >
  31. >Are you serious? What if I'm writing a little embedded kernel that doesn't use
  32. >anything resembling the standard C library, and I use free() for something
  33. >quite different?
  34.  
  35. Could you, please, actually read the standard before continuing to post
  36. on this thread?  You'll find there a clear distinction between freestanding
  37. and hosted environments.
  38.  
  39. >This is truly silly. The standard may say one thing, but it's despicable to
  40. >actually implement a compiler that treats free() specially. There is nothing in
  41. >the semantics of free() that requires special treatment in order to do its job.
  42.  
  43. It's not in the semantics, it's in the fact that "free" is in the 
  44. implementation namespace, and, like all the other names there, cannot be
  45. redefined without invoking undefined behaviour.  What's so difficult to
  46. understand?
  47.  
  48. >For one thing, malloc() is far from a perfect allocation scheme, so why give it
  49. >preferential treatment? I might design my own library which uses allocation
  50. >handles, and performs heap compaction, for instance.
  51.  
  52. You can't implement your own library in ANSI C (unless you use a statically
  53. allocated heap :-) so the point is moot as far as c.l.c is concerned.
  54.  
  55. >>>It's just another function, after all.
  56. >>
  57. >>No, it isn't.  Have a look at the standard.
  58. >
  59. >I just had a look at the sources for my standard library. It sure looks like a
  60. >function to me. (Walks like a duck, quacks like a duck, ... )
  61.  
  62. Even if it is a function, it is part of the implementation and this is what
  63. makes it different from the functions defined by your application.
  64.  
  65. You can't have two different functions with the same name and global scope
  66. in your program, right?  Then why do you expect free() to be different?
  67. Only because the implementations _you_'ve worked with allowed this?
  68.  
  69. >I wonder whether the seats of that ANSI commitee were actually populated by
  70. >programmers.
  71.  
  72. Is this supposed to be a lame excuse for your ignorance in matters of 
  73. standard C?  The members of the ANSI commitee had a little bit more 
  74. experience in matters of programming and on a little bit more platforms 
  75. than you.
  76.  
  77. Dan
  78. -- 
  79. Dan Pop
  80. CERN, CN Division
  81. Email: danpop@mail.cern.ch 
  82. Mail:  CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland
  83.